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This paper presents a novel approach for augmenting proof-based verification with performance-style 
analysis of the kind employed in state-of-the-art model checking tools for probabilistic systems. 
Quantitative safety properties usually specified as probabilistic system invariants and modeled in 
proof-based environments are evaluated using bounded model checking techniques I?). 

Our specific contributions include the statement of a theorem that is central to model checking 
safety properties of proof-based systems, the establishment of a procedure; and its full implemen- 
tation in a prototype system (YAGA) which readily transforms a probabilistic model specified in a 
proof -based environment to its equivalent verifiable PRISM (TU\ model equipped with reward struc- 
tures 1 1 1. The reward structures capture the exact interpretation of the probabilistic invariants and can 
reveal succinct information about the model during experimental investigations. Finally, we demon- 
strate the novelty of the technique on a probabilistic library case study. 

1 Introduction 

There are two main techniques for investigating quantitative properties of probabilistic systems be- 
haviours: 

Probabilistic model checking comprises the formalisation of a model (which describes a system op- 
erationally), and a suite of algorithms to analyse various correctness and performance properties (usually 
expressed as a probabilistic temporal logic) of the model. 

Proof-based verification on the other hand are practical applications of deductive proof methods to 
establish a link between the operational description of the model and the desired properties. 

Over the years these two techniques have developed almost independently. The goal of this paper is 
to establish a formal link between them in a way that has never been previously explored. Our intention is 
to make such linkage beneficial to practitioners of both techniques, and hence ensure future applicability 
of the proposed practice especially on an industrial scale. 

The B -Method IS is an industrial-strength specification language for describing large-scale abstract 
system behaviours. The method's development process ensures that specifications gradually evolve via 
refinement to implementable code. The probabilistic B (pB) Q extends the B -Method to incorporate 
probability. 

PRISM 1 10| is a probabilistic model checker which accepts probabilistic models described in its 
modeling language — a simple state-based language. Three types of probabilistic models are supported 
directly — Discrete Time Markov Chains (DTMCs), Markov Decision Processes (MDPs), and Continu- 
ous Time Markov Chains (CTMCs). This work is based on the the MDP type of the language. 

*The author is a recipient of the Australian Commonwealth Endeavour International Postgraduate Research Scholarship 
(E-IPRS) while pursuing a Ph.D. in the Information and Networked Systems Security (INSS) research group at Macquarie 
University, Australia. 



S. Andova et.al. (Eds.): Workshop on Quantitative Formal Methods: 

Theory and Applications (QFM'09) 

EPTCS 13, 2009, pp. 27-f39] doi: 10.4204/EPTCS. 13.31 



© Ukachukwu Ndukwu 

This work is licensed under the 

^C reative Commons Attributio n License. 



28 



Linking Proof-Based Verification with Model Ctiecking 



One of the key features of the pB language is the statement of invariants — they provide a means of 
describing properties required to maintain the integrity of a system under construction. In an attempt to 
establish a generalised view of probabilistic system invariant properties, Hoang T.S. et al. [14J originally 
explored the use of "expectations" as system invariants in proof-based systems. Including probabilistic 
invariants in systems design is a useful means of enforcing quantitative safety properties — for example, 
tolerance for expected error in a probabilistic system behaviour. 

Discharging a pB machine's safety proof obligation involves the verification (by a human or auto- 
mated support) that indeed the expectation holds for all executions of the machine; but sometimes the 
prover fails to establish this goal. It is pertinent to mention that not all the undischargeable proof obliga- 
tions are malignant to the overall performance outlook of the final machine for deployment. However, in 
safety-critical systems development, this assumption cannot be taken lightly hence the need to explore 
other techniques of gaining intuition into the failure of the provers to discharge their proof obligations. 

For standard (non-probabilistic) B machines, a prototype system ifTSl which incorporates a model 
checking tool has been used to detect various errors in simple machine specifications. However, for the 
probabilistic counterparts, we show how to link the model checking facility of PRISM with abstract 
systems specified in pB via the latter's probabilistic invariants. The importance of such a link is to enable 
pB designers explore their models experimentally; such an exploration is likely to reveal undesirable 
performance attributes of their models, and in particular guide them with a decision in the event that the 
invariants fail to hold. 

Our technique is as follows. Given a proof -based machine specified in pB, we generate its equivalent 
probabihstic action systems representation (in the PRISM language) fully augmented with reward struc- 
tures [1] inherited from the pB machine's expectations, and either confirm (or refute) the statement over 
the expectations. In the event that the statement fails to hold, we get an intuition of the possible cause(s) 
of failure. Our specific contributions are as follows: 

(a) The statement of a theorem that forms the implicit link between a pB invariant and its reward- 
based model checking equivalent. 

(b) A procedure for transforming a pB machine specified in a proof -based environment to its equiva- 
lent PRISM representation. 

(c) A prototype system to automate the procedure. In addition, we equip the resultant PRISM model 
with reward structures inherited from the pB machine's expectations, to allow for experiments. 

(d) A demonstration of the novelty of our technique on a small case study of a probabilistic library 
system. 

Overall, this paper is structured as follows. We introduce the pGSL and its expectations in sec. 2, and set 
the theoretical foundation of our procedure in sees. 3, and 4. The automation of that procedure is in sec. 
5. A practical demonstration of our technique is in sees. 6 and 7. Finally, we conclude in sec. 8. 

2 Probabilistic Generalised Substitution Language pGSL 

Abrial's Generalised Substitution Language GSL f3l is based on Dijkstra's weakest-precondition wp 
semantics of describing computations and their meaning |5|. The semantics, expressive in the B-Method 
(B) IS, defines the concept of an "abstract machine". The Abstract Machine Notation (AMN) explores 
B's capabilities via refinement for incrementing designs such that relevant system properties are always 
preserved. The complete framework supports the development of provably correct systems. 
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Figure 1: Structural definition of the expectation transformer-style semantics. 

The logic pGSL fTP] is a smooth extension of the GSL, in which the standard boolean values — 
representing certainty are replaced by real- values — representing probability. Its logical framework is the 
probabilistic Abstract Machine Notation (pAMN) [7], an extension of the standard AMN. Its specification 
is based on the probabilistic B (pB). The syntactic structure of the pGSL is rich enough to permit the 
specification of abstract probabilistic system behaviours. Details of the GSL can be found in Q, while 
that of its theoretical and practical extensions are in 1 11 1 and 1 14, 7 1 respectively. 

An important component of the pGSL is the specification of probabilistic invariants to ensure con- 
sistency between system designs. This is indeed crucial since it also assures that undesirable operation 
sequences do not lead to a violation of the critical properties of a system. In fact, the semantics of the 
pGSL which is based on the expectation transformer-style semantics of pGCL [9] (shown in Fig. [T]) gives 
a complete characterisation of probabilistic programs with nondeterminism, and they are sufficient to ex- 
press many performance-style properties. To further explore this capability, we set out the definitions 
below. Their elementary details can be found elsewhere fT3l[T6l . 

Definition 1: (Sub-distribution) For any finite state space S, the set of sub-distributions over S is 

{A:5^[0,1]IIA<1}, (1) 

the set of functions from S into the closed interval of reals [0,1] that sum to no more than one^ 
Definition 2: (Labeled Markov Decision Process) A tuple (S, s, A, L), where S is as defined above, f € 5 
is the initial state, A:S —*2^ is a transition function, and L: S ^ is a labeling function which assigns 
to each state, a subset of the set of atomic propositions AP that are valid for that state. 
Definition 3: (Path) A path in an MDP is a non-empty finite or infinite sequence of states sq s\ 
... where a,- G A{si) and a,(5,+i) > for all Si G S. 

Definition 4: (Absorbing state) A state Si £ S is said to be absorbing if no transition leaves this state 

after resolving all the nondeterministic selections in the state i.e., Si si, and Si sj whenever i ^ j. 

A probabilistic computation tree formalises the notion of a probabilistic distribution over execution 
traces required to give semantic interpretation to temporal properties. Each step on a path will have an 
associated probability (often probability one for standard steps in the computation) — and the probabil- 
ities on those individual steps when multiplied together, determine probability for paths ending up in a 
particular absorbing state. Our interest hes in only using such probabilities masses for finite paths. 



Probabilities that sum to less than one represent aborting behaviours. We do not discuss such program behaviours here. 
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Definition 5: (Endpoint of a distribution) Any absorbing state s over the distribution A is said to be at 
the endpoint of the distribution. 

Definition 6: (Random variable) A random variable is a non-negative real-valued function over the state 
space in which our programs operate. 

Definition 7: (Expected value) For any bounded random variable a /« 5 — > M> and distribution A € 5, 
the expected value of a over A is defined 

j a = Y.^a.s*^.s) , (2) 

for any state s in the endpoint of the distribution A. 



2.1 The PCHOICE Operator 

In lfT4l Hoang T.S. et al. introduced a PCHOICE operator in the standard AMN's operations — sim- 
ilar to the probabilistic choice operator of Fig. [T] which also permits the specification of probabilistic 
behaviours in a typical machine. This extension, captured in the the probabilistic Abstract Machine No- 
tation (pAMN), and expressed in the pB method, describes probabilistic machines with an additional 
EXPECTATIONS clauseH. Ideally, probabilistic invariant properties are then defined as random vari- 
ables over the machine's state, and encoded in the EXPECTATIONS clause. An invariant of this form is 
then an "expected value-invariant". Later on, we show how the pAMN can be used to specify abstract 
probabilistic system behaviours. A comprehensive list of the pAMN clauses can be found in Q. 

2.2 The EXPECTATIONS clause 

It gives a random variable t, over the program state, denoting the expected value-invariant, and an initial 
expression e which is evaluated over the program variables when the machine is initialised. The idea 
is that after arbitrary executions of the program, the expected value of t, at any given program state, is 
always at least the value of e initially lfT4l . 

More formally, suppose a probabilistic machine has initialisation INIT and two operations OpX 
and Op y respectively, therefore, satisfying the probabilistic proof obligation for some expected value- 
invariant and initial expression e would operationally (Fig. [U imply thaH 

E,^wp.OpX.£, and t,^wp.OpY.E, provided e ^wp.INIT.^, (3) 

which then assures that 

e ^ wp.INIT.{wP.{lt OpX n OpY tl).<^). (4) 

The operational interpretation of Q is that arbitrary interleaving of the operations OpX and OpY after 
the initialisation INIT should always result in a distribution over the final states (of variables) such that 
the expected value (with respect to invariant ) is at least the initial value specified by the expression e. 
Clearly, the conditions in Q imply the operational interpretation of (HJl. However, if there is a particular 
interleaving of the machine which demonstrates the failure of Q, then it must be true that ([3]) has hitherto 
failed as well. The example below illustrates our argument. 

^The complete framework encapsulates state variables and the operations on the states by the use of 'clauses'. 
^For random variables R, R , the implication-like relation R^ R means R is everywhere less than or equal to R . 
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MACHINE 
SEES 

VARIABLES 
INVARIANT 
EXPECTATIONS 
INITIALISATION 
OPERATIONS 
nn ^ OpX = 



OpY 



Demon 

InLTYPE, ReaLTYPE 

cc 

cc : INT 
real{0) ^ cc 
cc := 

BEGIN 

PCHOICE /rac(l,2) OF cc:=cc- 
OR cc :=cc-l END \ \nn:=cc 
cc := 



END 



Figure 2: A pB model specified in the pAMN. 
2.2.1 Example: A Simple Demonic Machine 

Fig. |2] shows a pAMN (adapted from fT4l) that captures the operations of a simple pB machine called 
Demon, with a single variable cc; the INVARIANT clause specifies that cc must be Integer-valued — 
pB 's prover always checks that this statement is true using the operational reasoning established in the 
previous section. Initially, cc is set to 0; the OPERATIONS clause contains operations OpX and OpY. 
OpX can either increment cc by 1 or decrement it by the same value both with probability 1 /2, while OpY 
just re-initialises cc to 0. The variable nn in the operation OpX is an output parameter which need not 
occur m the VARIABLES clausal The EXPECTATIONS clause specifies the expected value-invariant 
^ to be the random variable cc, and the initial expression e to be 0, so that "the expected value of cc over 
any endpoint distribution is never decreased below 0" by the Demon's OpX and OpY operations. 

In this example, the machine fails to satisfy the probabilistic proof obligation specified in dJ]), and 
the reason is that 

{3cceINT: -n{cc ^ wp.OpY.cc)). (5) 

The immediate expression captures the failure of the pB prover to establish the proof obligations in 
However, in terms of a distribution viewpoint, it is possible to see exactly why this failure of the pB 
prover would similarly result in the failure of (01). Consider the program fragment 

INIT; OpX; {OpY < {nn > 0) > skip); (6) 

it yields the distribution given by 

r cc:=0 @l/2 
\ cc:=-l @l/2 

over the final state of the random variable cc. Calculating the expected value over this distribution we get 

cc= l/2x0+l/2x -1 =-1/2, 

which is clearly a violation of the conditions specified in the EXPECTATIONS clause. 

In this simple case, it is clear that the failure to establish the pB proof obligation corresponds to 
an exact result distribution over endpoints that demonstrates the failure. Currently pB provers do not 



^It must however follow a similar machine declaration as cc to enable its PRISM transformation. 
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provide diagnostic information necessary to give practitioners the much needed operational intuition (in 
terms of distributions) for locating failures. This becomes even more complicated with increasing size 
and complexity of the pB machines. For such cases, we simply rely on the model checking capabilities 
of state-of-the-art tools like PRISM. To do this, we need to translate the pB machines to their equivalent 
PRISM models, and use the latter's algorithmic analysis to attempt to locate failures. 

In the sections that follow, we show how the analysis of an equivalent PRISM representation of 
a pB machine can provide a link between the operational viewpoints (distribution-centered) of both a 
proof-based environment (encapsulating probabilistic invariants), and a model checking platform. Such 
a link is key to getting a better understanding of the expected value-invariants over endpoint probabilistic 
distributions. 



The PRISM model checker permits models to be augmented with information about rewards (or costs). 
The tool can analyse properties which relate to the expected values of the rewards. A reward structure 
ifn can be used to represent additional information about the system the MDP (the model types in this 
paper) represents — for example, the expected number of packets sent (or lost) on a protocols request. 

The temporal logic probabilistic CTL lfT2l has been extended in ||2l to allow for reward-based spec- 
ifications as constraints of the type that express reachability, cumulative and instantaneous rewards to 
model checkers. However, for the purpose of this work, the instantaneous variant is useful. 
Definition 8: (Expected instantaneous reward) The probabilistic CTL permits reward properties of 
the form Rr^r^^^], at time-step k, where ~€ {<,<,>,>}, rE M> and /c G N. The reward formula 
true if from some initial state sq, the expected state reward at time-step k meets the bound 
~ r. For example the specification R>5q [I^^] could be interpreted to mean that the expected number of 
packets sent by the protocol after two time-steps is at least 50. 

4 Quantitative Safety and pB Machines 

Formal approaches necessitate that every safe system be invariant-driven [5|. Therefore, quantitative 
safety properties can be proved by verifying invariants. The EXPECTATIONS clause of a pB machine 
encapsulates the machine's safety property. However, an interesting dimension in investigating pB safety 
properties is whether it is possible to find a nondeterministic selection no<„<w Pn of the operations of the 
machine that demonstrates the failure of the invariants — this schedule must then lead to the problem of 
locating counterexamples for probabilistic model checking 0. 

In m Mclver et al. set out a strategy for computing a "refutation-of-safety" certificate for probabilis- 
tic systems using model checking techniques. The existence of a certificate corresponds to an invariant 
failure in our own context of safety. In the next section, we present an automation which demonstrates the 
key features of that strategy and in particular show how it can be used to investigate pB safety properties. 
The theorem below is fundamental for investigating safety properties specified for pB machines. 
Theorem: Given a pB machine invariant t, and initial expression e encapsulated in the machine's EX- 
PECTATIONS clause, let Abe the finite result distribution over endpoints for the interleaving It no<n<A? Pn tl 
after the machine 's initialisation INIT. A safe machine always guarantees that 



^For MDP's we require Rmin or Rmax; this is allowed in PRISM by enabling the sparse engine in the tool's options menu. 



3 PRISM Reward Specification 



e ^ wp.INIT .{wp.{\t no<„<w Pn^l)-^) ^ 




(7) 
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provided the pB machine's prover will always discharge the proof obligations given by e ^ wp.INIT 
and E, ^ w/?.(It no<,j<A? tl).i^ respectively. 

Corollary: Suppose it is always possible to split the distribution A into finite sub-distributions 8k for all 
k>0 where 5k is the result distribution on the kth iteration, then 



The usefulness of the corollary is in the practical demonstration of the theorem. Its simplicity is captured 
by the fact that, if a probabilistic computation tree which interprets the execution traces of the machine 
is available to a verifier, then these traces must be finite with respect to the result distributions they 
represent. Using bounded model checking techniques, it then suffices to argue that only finite values 
of k are required to establish the proof obligation for a safe pB machine. More so, with state-of-the-art 
probabilistic model checking tools such as PRISM, it is possible to identify a sub-space of the entire 
distribution in which the failure is located (if any). 



In section IH we stated a theorem that is central to defining safety features for pB machines with a 
finite trace distribution over endpoints. The corollary of that theorem has the practical interpretation 
that, bounded model checking techniques when equipped with reward structures are likely to provide an 
intuition to locating invariant failures in their transformed proof-based models. In this section we discuss 
a language-level translator nicknamed YAGJ!@ and with architectural framework shown in Fig. [3] YAGA, 
a java-based implementation of the algorithm pAMN2PRISM (shown in Appendix A) is a prototype 
system that essentially takes a pAMN framework, encapsulating a pB model (with syntactic checks 
supposedly discharged) as its input parameter, and generates its precise probabilistic action systems 
representation in the PRISM language. The associated reward structure of the generated PRISM model 
is inherited from the pB machine's EXPECTATIONS clause. The PRISM model checker then readily 
offers its temporal logic specification (as probabilistic CTL formulas) which can easily be checked by 
conducting experiments on the transformed model. The experimental results are sufficient to validate (or 
refute) the probabilistic invariants specified in the abstract machine's EXPECTATIONS clause. 

5.1 Overview: YAGA Transformation Rules 

We summarise the transformation rules as follows. YAGA's algorithmic interpretation is in Appendix A. 
5.1.1 Main Module 

PRISM constants list: Are constructed from the pB machine's parameter list (if any) and the CON- 
STANTS clause. The type of a constant is implicitly checked from the PROPERTIES clause. 
PRISM formula list: Are auto-generated as atomic predicates from the pB machine's PROPERTIES 
and INVARIANTS clauses. 

PRISM module name: Is the pB machine's name. 

PRISM variables declaration and initial values list: Are constructed from each variable in the VARI- 
ABLES clause, its type in the INVARIANT clause, and its initial values from the INITIALISATION 

''The name YAGA is coined from an Igbo (a language largely spoken in southeastern Nigeria) word — YAGAzie, which 
literally means "may it go well In reality, it could be argued that YAGA is simply Yet Another Gangling Automation. 




(8) 



5 YAGA: A pAMN To PRISM Translator 
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TRANSFORMATION RULES PRISM 




INPUT pB MODEL OUTPUT VERIFIABLE PRISM FILE 



Figure 3: YAGA - Architectural Overview 

clause. The lower and upper limits of the variables are respectively the default lowest values of their 
types, and a bound specified from the PRISM constants list (above). 

PRISM update statements: Each update statement is labeled with the operation's name from the pB 
machine. In addition, 

(a) its guard is inherited from the guard in the pB machine's OPERATIONS clause and strengthened 
by the formulas in the PRISM formula list, such that 

(b) the choice of a selection of formula is dependent on the expressions in the pB machine's update 
statement. For each update, YAGA checks that the formula-dependent expressions are included in 
the PRISM guard. 

5.1.2 Counter Module 

The counter module is a vital encoding that helps enumerate the distributions in 5^ (in corollary) for 
finite k steps. To capture this behaviour in a model checking environment, we apply the following rules. 
PRISM module name: Counter. 

PRISM variable declaration and initial value: Variable count is initially set to and bounded by 
{MAX_COUNT + \). 

PRISM update statement: Each update is constructed to synchronise with the updates in the main mod- 
ule. They can only increment the count variable by 1 on each action. In addition, this module also contains 
a similar unsynchronised update statement which ensures we will eventually reach {MAXjCOUNT + 1). 

5.1.3 Reward Structure 

The specific reward structure is inherited from the pB machine's EXPECTATIONS clause — states 
where the count variable equals {MAXjCOUNT + 1) are worth the random variable value specified in 
the EXPECTATIONS clause plus {MAX .COUNT f\. 

However, to make the construction of our reward structures precise for model checking, we note 
more formally as a result of the theorem in sec. |4]that 

Remark 1: Given any pB machine invariant t, and initial expression e, then from an initial state sq, after 
the machine's initialisation INIT, ciny arbitrary interleaving It no<,7<w Pn tl must guarantee that: 

{k :G [0,MAX_COUNT + \] : e ^ wp.INIT .{wp.{lt no<„<wP„ tl).^) ^ Rmin=7[I=''] >^.sq) (9) 



^This padding is to ensure the PRISM engine is consistent with computing positive instantaneous rewards. Finally, we 
subtract this parameter from the PRISM computed reward value. 
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such that the expected minimum instantaneous reward at the kth step is worth the random variable value 
of the EXPECTATIONS clause plus MAX JO OU NT. We recall that the Counter module keeps explicit 
track of the kth time-step, and the expected value here is captured by the sub-distribution in dS]). 
Remark 2: However, if there exists some k such that dP]) above fails to hold, then t, cannot be an invariant. 

6 Case Study: A Library Bookkeeping System 

We present a pB machine which captures the basic operations underlying the accounting package of a 
hbrary system — the implication of an undischargeable proof obligation of the machine on the perfor- 
mance of the library was an open problem in [14J. The state of the machine contains four variables: 
books InLibrary, loansStarted, loansEnded and booksLost which are respectively used to keep track of: 
the number of books in the library, the number of book loans initiated by the library, the number of book 
loans completed by the library, and the number of books possibly never returned to the library. 

Initially, the machine has two operations: StartLoan, to initiate a loan on a book, and EndLoan, to 
terminate the loan of a book. The StartLoan operation has a precondition that there are books available for 
loan; it decrements booksInLibrary and increments loansStarted; when a book is returned, the EndLoan 
operation reverses the effect of the StartLoan operation by recording that either the book "really is" 
returned, or is actually reported lost with some probability pp, so that booksLost is incremented. 

The machine uses the random variables loansEnded and booksLost to record the expected losses of 
the number of books over time. Since with a probability pp a book is lost on each EndLoan operation, 
the library system would then be expected to lose a proportion pp over a number of EndLoan operations. 
However, to ensure that the library is always in the business of books lending, we define the expected 
value-invariant 



which captures the idea that the expected value of the random variable pp x loansEnded — booksLost 
over its endpoint distributions A can never be decreased below 0. This is indeed a safety property for the 
library and ought to be checked throughout its lifetime to ensure it is not violated by its future designs. 
Below, we present two designs of the library and also keep in mind the property specified in (ITOl) . 

6.1 A Safe Library Bookkeeping System 

Since there are no restrictions on when the operations of the machine can be invoked, except for the 
obvious preconditions on StartLoan and EndLoan; the specification of a safe library system is the non- 
deterministic choice given by 



6.2 An Unsafe Library Bookkeeping System 

Suppose that to enable the library accountant do a periodic stock take of the library transactions, a new 
operation called StockTake is introduced into the system. The StockTake operation is very similar to the 
initialisation, except for an extra output (totalCost) to record the cost of replacing the books lost up to 
the time of doing a stock take. Again, we augment (fTTT) and give another specification of the library as 



The complete pB machine describing the library (all of its three operations) is shown in Appendix A. 




(10) 



SafeLibrary = It StartLoan □ Endloan tl . 



(11) 



U nsaf eLibrary = It StartLoan □ Endloan □ StockTake tl . 



(12) 
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Without StockTake 
With StockTake 




1 2 3 

Time step, k 



Figure 4: Library Bookkeeping System 

7 PRISM Experimental Results 

In this section we report experimental results that are indeed performance-style characterisations of the 
two designs of our library model — the safe library (fTTI ) and the unsafe library ([T2l ). Our interest lies in 
justifying the reason why one design of the library (without StockTake) is safe and why the other (with 
StockTake) is unsafe. We note that our safety property of concern is captured by (fTOl) . 

To enable us carry out this performance analysis, we quickly use the capabilities of YAGA. The 
equivalent PRISM representation of the pB machine discussed in the previous section as generated by 
YAGA is shown in Appendix A. From Remark 1, our obvious reward specification becomes 

{yO<k< MAXJOOUNT : Rmin=-^ [1=^] - MAXjCOUNT) . (13) 

The requirement for a safe library system is that for all time-steps k, Rmin is never decrease below zero. 
However, our experimental result (shown in Fig. S]) reveals that indeed the unsafe library violates this 
safety property after just three time-steps {k = 3) of its execution — that is for MAXjCOUNT = 2, 
pp = 0.5, and totalBooks = 1, the expected minimum instantaneous reward Rmin of the unsafe library 
is -0.25. 

A quick conclusion that can be drawn from our analysis is that introducing the "demonic" StockTake 
operation has the adverse effect of subverting the overall performance outlook of the library system. Our 
result is a practical demonstration of the claim by Hoang T.S. et al. lfT4l in an attempt to explain why the 
presence of the StockTake operation would result in a failure of the proof obligation for the probabilistic 
invariant property in (ITOl ). In the proof-based system, reaching this conclusion was practically impossible. 

8 Conclusion and Future Work 

This paper has explored the practical application of reward-based specifications of bounded model check- 
ing techniques H to locate failures in the context of proof-based verification for simple safety properties 
of probabilistic systems. We demonstrated the rich benefits that can be derived by complementing proof- 
based probabilistic verification techniques with a model checking performance-style evaluation, in a 
manner that has never been previously explored. 

Our contribution is seen as a first attempt at fully integrating quantitative performance analysis to 
systems design at early stages of development. Our method scales in this regard since it can be carried 
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out at the level of source code and hence can guide system developers with decisions on a choice of 
design most suitable for implementation. 

However, in other to fully integrate this performance-style analysis into software development pro- 
cess, we intend to, in the future, incorporate a diagnostic mechanism based on counterexamples location 
employed in IS] [171 to YAGA. Our intention is that such a mechanism will report explicit cause(s) of fail- 
ure by also exploring the backward analysis strategy in f8]. It is our belief that these enhancements would 
provide a useful performance analysis suite for probabilistic systems developed in the pB language. 
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Appendix A 



MACHINE ProbabilisticLibrary (totalBooks. cost) 
SEES ReaLtype 
CONSTANTS pp 

PROPERTIES pp e REAL A pp < real (l) A real (0) < pp 

VARIABLES booksInLibrary, loansStarted, loansEnded, booksLost, totalCost 

INVARIANT bookslnLibrray, loansStarted, loansEnded, booksLost, totalCost e NATURAL A loansEnded < loansStarted 

A booksInLibrary + booksLost + loansStarted - loansEnded = totalBooks 
EXPECTATIONS real (0) ^ pp x real (loansEnded) ~ real(booksLost) 

INITIALISATION booksInLibrary, loansStarted, loansEnded, booksLost, totalCost := totalBooks, 0, 0, 0, 
OPERATIONS StartLoan = PRE booksInLibrary > THEN 

booksInLibrary /= booksInLibrary - 1 \ \ loansStarted := loansStarted + 1 END; 
EndLoan = PRE loansEnded < loansStarted THEN 

PCHOICE pp OF booksLost /= booksLost + I 

OR booksInLibrary /= booksInLibrary + 1 END || loansEnded : = loansEnded + 1 END; 
StockTake = BEGIN totalCost := cost x booksLost \ \ booksInLibrary := booksInLibrary + booksLost \ 
loansStarted := loansStarted - loansEnded \ \ loansEnded .'=0 11 booksLost := END 

END 



Figure 5: The pB Model of Section Q 



const totalBooks; 
const cost; 
const double pp; 
const MAX.COUNT; 



formula formulaO = (loansEnded < loansStarted); 

formula formulal = (booksInLibrary + booksLost + loansStarted - loansEnded = totalBooks); 

formula formulal = (pp < 1); 

formula /ormu/a J = (0<pp); 



module ProbabilisticLibrary 
booksLost: [ 0. . totalBooks] 
totalCost; [ 0. . totalBooks] 
loansEnded: [0. . totalBooks ] 
loansStarted;] 0. . totalBooks] 
booksInLibrary: ]0. . totalBooks] 



init 0; 
ink 0; 
init 0; 
init 0; 

init totalBooks: 



]StockTake] formulal & formulaO — > (totalCost ' = cost * booksLost) & (booksInLibrary ' = booksInLibrary + booksLost) 

& (loansStarted ' = loansStarted - loansEnded) & (loansEnded ' = 0) & (booksLost ' = 0); 

]StartLoan] (booksInLibrary > 0) & formulal & formulaO & (loansStarted + I < totalBooks) 

(booksInLibrary ' = booksInLibrary - 1) & (loansStarted ' = loansStarted + 1); 

]EndLoan] (loansEnded < loansStarted) & formulal formulal &formula3 & formulaO 

pp: (booksLost ' = booksLost + I) & (loansEnded ' = loansEnded + 1) 

+ (I - pp); (booksInLibrary ' = booksInLibrary + 1) & (loansEnded ' = loansEnded + I); 

endmodule 



label "expectations" = (pp * loansEnded - booksLost > 0); 



module Counter 

count: ]0..MAX.COUNT + 1] init 0; 

]StockTake] (count + I < MAX.COUNT + 1) ^ (count ' = count + I); 
]StartLoan] (count + I < MAX.COUNT + 1) ^ (count ' = count + 1); 
] EndLoan] (count + I < MAX.COUNT + I)^ (count ' = count + I); 
]] (count + I < MAX.COUNT + 1)^ (count ' = count + 1); 
endmodule 



rewards 

(count = MAX.COUNT + 1); (pp * loansEnded - booksLost) + MAX.COUNT; 
endrewards 



Figure 6: A YAGA-Generated PRISM Representation of Fig. 



Ukachukwu Ndukwu 



Algorithm pAMN2PRISM (pB_model_in_pAMN) 



Required: An interface for pB syntax, PRISM syntax, and regular math operators. 
Reserved: MAX.COUNT (constant), count (variable) 
1 : get pAMN parameter list if any 

2: create a map object with pAMN clauses as the the keys. Insert their respective values 
3: construct value objects with (1) and (2) 
4: set module type as MDP 

5: construct PRISM constants list from the pAMN parameter list and PROPERTIES key 
6: construct PRISM formula hst as atomic predicates from the INVARIANT and 

PROPERTIES keys 
7: get PRISM module name from MACHINE key (declare module name) 
8: construct PRISM variables list and their initial values from the VARIABLES 

and INVARIANT keys and the pAMN parameter list (if any) 
9: for the OPERATIONS key in the map object do 
get the list of operations 
for each operation in the list do 

for each guard and update statement in operation do 
check variables dependency on (6) 
10: construct PRISM update statements with the pAMN operations names as the 

action labels 
1 1 : declare endmodule 

12: construct expectations label from the EXPECTATIONS key in map object 
13: declare module counter 

14: declare count variable, initialised to zero and bounded by MAX_COUNT + 1 
15: for the OPERATIONS key in the map object do 
get the list of operations 
for each operation in the list do 

construct a synchronised update statement (increment) on the count 
variable with (10) 

16: construct an unsynchronised update statement on the count variable 
17: declare endmodule 
18: declare PRISM rewards 

19: for states where (count = MAX.COUNT + 1) 

20: set reward to random variable value on EXPECTATIONS key plus MAX.COUNT 
21: declare endrewards 



Figure 7: An Algorithmic Description of YAGA 



